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An IPv6 Provider-Based Unicast Address Format 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


1.0 Introduction 


This document defines an IPv6 provider-based unicast address format 
for use in the Internet. The address format defined in this document 
is consistent with the "IPv6 Addressing Architecture" [ARCH] and the 
"An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is 
intended to facilitate scalable Internet routing. 


The unicast address format defined in this document doesn’t preclude 
the use of other unicast address formats. 


2.0 Overview of the IPv6 Address 


IPv6 addresses are 128-bit identifiers for interfaces and sets of 


interfaces. There are three types of addresses: Unicast, Anycast, 
and Multicast. This document defines a specific type of Unicast 
address. 


In this document, fields in addresses are given specific names, for 
example "subscriber". When this name is used with the term "ID" (for 
"identifier") after the name (e.g., "subscriber ID"), it refers to 
the contents of the named field. When it is used with the term 
"prefix" (e.g., "subscriber prefix") it refers to all of the address 
up to and including this field. 


Rekhter, et. al. Standards Track [Page 1] 


RFC 2073 IPv6 Provider-Based Unicast Address Format January 1997 


The specific type of an IPv6 address is indicated by the leading bits 
in the address. The variable-length field comprising these leading 
bits is called the Format Prefix (FP). 


This document defines an address format for the 010 (binary) Format 
Prefix for Provider-Based Unicast addresses. The same address format 
could be used for other Format Prefixes, as long as these Format 
Prefixes also identify IPv6 unicast addresses. Only the "010" Format 
Prefix is defined here. 


3.0 IPv6 Provider-Based Unicast Address Format 


This document defines an address format for the IPv6 provider-based 
unicast address assignment. It is expected that this address format 
will be widely used for IPv6 nodes connected to the Internet. 


The address format defined in this document conforms to the 
"Architecture for IPv6é Unicast Address Allocation" [ALLOC]. 
Specifically, the format is designed to support aggregation of 
network layer reachability information at multiple levels of routing 
hierarchy. 


For addresses of the format described in this document the address 
administration is organized into a three level hierarchy -- registry, 
provider, and subscriber. The address format defined here allows 
flexible address allocation at each level of the address 
administration hierarchy in such a way as to support a wide spectrum 
of demands for address allocation. 


This document assumes that the Internet routing system doesn’t make 
any assumptions about the specific structure and semantics of an IPv6 
address, except for the structure and semantics of the Format Prefix 
part of the address, and the use of the "longest prefix match" 
algorithm (on arbitrary bit boundaries) for making a forwarding 
decision. 


The address format defined in this document is intended to facilitate 
scalable Internet-wide routing that does not impose any constraints 
on connectivity among the providers, as well as among the providers 
and subscribers. 
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3.1 Provider-Based Unicast Address Structure 


For the purpose of address allocation, the address format defined in 
this document consists of the following parts: Format Prefix, 
Registry ID, Provider ID, Subscriber ID, and an Intra-Subscriber 
part. The Intra-Subscriber part definition is the responsibility of 
the subscriber and is not defined in this document. The provider- 
based unicast address format is as follows: 


The following sections specify each part of the IPv6 Provider-Based 
Unicast address format. In general other allocation strategies are 
possible within this framework, but the ones described in this 
document will be used to assign IPv6 provider-based addresses. 


3.2 Registry ID 


With the growth of the Internet and its increasing globalization, 
much thought has been given to the evolution of the Network Layer 
address space allocation and assignment process. RFC 1466, 
"Guidelines for Management of IP Address Space", proposes a plan that 
defines distributed allocation and assignment of the IPv4 address 
space. 


As the Internet transitions to IPv6é, the plan for distributed 
allocation and assignment of the IPv4 address space established in 
RFC1466 forms a base for the distributed allocation and assignment of 
the IPv6é address space. 


The Internet Assigned Number Authority (IANA) is the principal 
registry for the IPv6é address space. The IANA may allocate blocks of 
IPv6 addresses and delegate the assignment of those blocks to 
qualified Regional Registries. The IANA will serve as the default 
registry in cases where no delegated registration authority has been 
identified. 


The Registry ID of the IPv6 provider-based unicast address format is 
intended to facilitate a broad geographic address allocation and 


facilitate the operations of the distributed Regional Registries. 


The Registry ID immediately follows the format prefix part of an IPv6 
address. 
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At present there are three Regional Registries: INTERNIC, RIPE NCC, 
and APNIC. In addition, address allocation could be done directly by 
the IANA. Corresponding to this division of address allocation, this 
document defines the following Registry IDs: 


Regional Registry Value (binary) 
Multi-Regional (IANA) 10000 
RIPE NCC 01000 
INTERNIC 11000 
APNIC 00100 


All other values of the Registry ID are reserved by the IANA. 


Use of the Multi-regional Registry ID permits flexibility in address 
assignments which are outside of the geographical regions already 
allocated. The IANA will be responsible for managing address space 
registration under the Multi-Regional Registry ID. 


It is expected that the IANA, and any designated Regional Registries, 
allocate addresses in conformance with this overall scheme. Where 
there are qualifying Regional Registries established, primary 
responsibility for allocation from within that block will be 
delegated to that registry. 


A Regional Registry may have more than one block of addresses 
allocated to it (as a result the Registry would have multiple 
Registry IDs associated with it). 


3.3 Provider ID and Subscriber ID 


This document leaves the organization of the Provider ID and 
Subscriber ID portions of address up to individual registries. 
Particularly the registry needs to define how much address space is 
given to providers and their subscribers. There are several issues 
which must be addressed when doing this. These include: 


o There will likely be a mixture of providers of different sizes. 

o Small providers will grow to become large providers. 

o Large providers will lose customers and become small providers. 
In extreme cases, the registry will require them to return some 
of their address space to the registry. 

o Organizations which need to be multi-homed to more than one 
provider will request a Provider ID assignment. 


It is important that a registry design its Provider ID space to allow 
flexibility and at the same time use the address space efficiently. 
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3.3.1 Provider ID 


The value of the Provider ID associated with an address block a 
registry allocates to a particular provider uniquely identifies this 
provider within the registry. 


This document assumes that some subscribers may decide to acquire 
their address space directly from a registry, thus making their 
addresses independent of the provider(s) they are directly attached. 


3.3.2 Subscriber ID 


The structure and assignment strategy of Subscriber ID’s is specified 
by each provider. 


A (direct) provider may decide to group its subscribers into regions. 
This grouping may be useful when the (direct) provider is attached to 
another (indirect) provider at multiple points, as it allows the 
direct provider to exert a certain degree of control over the 
coupling between the attachment points and flow of the traffic 
destined to a particular subscriber (see Section 5.3.1 of [ALLOC]). 


To accommodate such a grouping the (direct) provider may allocate 
some small number of high-order bits of the Subscriber ID as a 
Subscriber-Region ID. The purpose of a Subscriber-Region ID is to 
identify a group of subscribers that are within a close topological 
proximity to each other (from the provider’s point of view), and thus 
could be reachable through a particular attachment point between the 
(direct) provider and other (indirect) provider(s). 


3.4 Intra-Subscriber Part 


This document leaves the organization of Intra-Subscriber portion of 
the address up to individual subscribers. 


The provider-based unicast address format described in this document 
leaves 64 bits for the local portion of the address. The editors of 
this document recommend that subscribers use IPv6 auto-configuration 
capabilities [AUTO] to generate addresses using link-specific 

addresses as Interface ID such as 48 bit IEEE-802 MAC addresses. In 
this case 16 bits are left for the Subnet ID. This should sufficient 


(e.g., 65,535 subnets) for all but the largest of subscribers. This 
is shown as follows: 
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Subscribers who need additional subnets (and who desire to continue 
to use 48 bit IEEE-802 MAC addresses for Interface ID’s) can be 
accommodated by having the provider assign them a block of subscriber 
prefixes. Alternatively, an extremely large subscriber could be 
assigned its own Provider ID which would give it additional bits of 
address space to create its own local address hierarchy. 


4.0 National Registries 


A Regional Registry may allocate blocks of address space to several 
National Registries. The National Registry then becomes the entity 
that allocates address space to individual providers within the 
country served by the National Registry. 


To create National Registries the Regional Registry may add a layer 
of hierarchy in the Provider ID field to create National Registries. 
The resulting Provider Prefix is as follows: 


|3 | 5 bits | n bits | mbits | 56-n-m ć | 64 bits | 
4---}---------- poses ese See 4+---------- +------------ 4+---------------- + 
|010|RegistryID| National | Provider | Subscriber |Intra-Subscriber| 

| |RegistryID| ID | ID | | 
faea KOE 4---------- Pee a esse 4$---------------- + 


This document assumes that within each regional registry there will 
be a relatively small number of national registries. The size of the 
National-Registry ID should be related to the number of countries in 
the region administrated by the regional registry and the number of 
providers expected to be in each country. 
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7.0 Security Considerations 

Security issues are not discussed in this memo. 
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